SRV record Totally Explained

Everything about Srv Record totally explained

An SRV record or Service record is a category of data in the Internet Domain Name System specifying information on available services. It is defined in RFC 2782. Newer internet protocols such as SIP and XMPP often require SRV support from clients. Client implementations of older protocols (for example LDAP, SMTP) may have SRV support added to it. However, this practice is discouraged by the SRV specification because it causes inconsistent behavior from one client to the next.

Record format

An SRV record has the form:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target

Service: the symbolic name of the desired service.
Proto: the protocol of the desired service; this is usually either TCP or UDP.
Name: the domain name for which this record is valid.
TTL: standard DNS time to live field.
Class: standard DNS class field (this is always IN).
Priority: the priority of the target host, lower value means more preferred.
Weight: A relative weight for records with the same priority.
Port: the TCP or UDP port on which the service is to be found.
Target: the canonical hostname of the machine providing the service.

An example SRV record might look like this:
_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.
Or like this using the non-standard djbdns syntax:
S_sip._tcp.example.com:::5060:5:0:86400:
This points to a server named sipserver.example.com listening on TCP port 5060 for SIP protocol connections. The priority given here's 0, and the weight is 5.
As with PTR records, SRV records must point to the canonical name of the host. Aliases or CNAMEs can't be used as valid targets.

Load balancing with SRV

The priority field is similar to an MX record's priority value. Clients always use the SRV record with the lowest-numbered priority value first, and only fall back to other records if the connection with this record's host fails. Thus a service may have a designated "fallback" server, which will only be used if the primary server fails. Only another SRV record, with a priority field value higher than the primary server's record, is needed.
   If a service has multiple SRV records with the same priority value, clients use the weight field to determine which host to use. The weight value is relevant only in relation to other weight values for the service, and only among records with the same priority value.
   In the following example, both the priority and weight fields are used to provide a combination of load balancing and backup service.
    _sip._tcp.example.com. 86400 IN SRV 10 60 5060 bigbox.example.com. _sip._tcp.example.com. 86400 IN SRV 10 20 5060 smallbox1.example.com. _sip._tcp.example.com. 86400 IN SRV 10 10 5060 smallbox2.example.com. _sip._tcp.example.com. 86400 IN SRV 10 10 5066 smallbox2.example.com. _sip._tcp.example.com. 86400 IN SRV 20 0 5060 backupbox.example.com.
   The first four records share a priority of 10, so the weight field's value will be used by clients to determine which server (host and port combination) to contact. The sum of all four values is 100, so bigbox.example.com will be used 60% of the time. The two hosts smallbox1 and smallbox2 will be used for 20% of requests each, with half of the requests that are sent to smallbox2 (for example 10% of the total requests) going to port 5060 and the remaining half to port 5066. If bigbox is unavailable, these two remaining machines will share the load equally, since that'll each be selected 50% of the time.
   If all four servers with priority 10 are unavailable, the record with the next highest priority value will be chosen, which is backupbox.example.com. This might be a machine in another physical location, presumably not vulnerable to anything that would cause the first four hosts to become unavailable.
   It should be noted that the load balancing provided by SRV records is inherently limited, since the information is essentially static. Current load of servers isn't taken into account.

Usage

SRV records are often used by Microsoft Windows 2000 clients to find the domain controller for a given service.
Further, SRV records are common in conjunction with the following standardised protocols:

Client SMTP Authorization

Kerberos

LDAP

SIP

XMPP (Jabber)Further Information

Get more info on 'Srv Record'.

External Link Exchanges

Do you know how hard it is to get a link from a large encyclopaedia? Well we're different and will prove it. To get a link from us just add the following HTML to your site on a relevant page:

<a href="http://srv_record.totallyexplained.com">SRV record Totally Explained</a>

Then simply click through this link from your web page. Our crawlers will verify your link, extract the title of your web page and instantly add a link back to it. If you like you can remove the words Totally Explained and embed the link in article text.
As long as your link remains in place, we'll keep our link to you right here. Please play fair - our crawlers are watching. Your site must be closely related to this one's topic. Any kind of spamming, dubious practises or removing the link will result in your link from us being dropped and, potentially, your whole site being banned.